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1 Introduction of Stream Recording Format 
1.1 Purpose of the Specification 

This DVD Stream Recording Specification is defined to use rewritable DVD discs for 
recording existing digital bitstreams, editing them and playing them back as bitstreams. 
The Specification is designed to satisfy the following requirements: 

1.1.1 Service Requirements 

1.1.L1 Individual Packet Size Support 

Any packet size should be supported as long as it is less than 2kByte and of constant 
length within a take. 

^01.2 Timing Regeneration 

A timing mechanism (time stamp) needs to be added to every broadcast packet to enable 
proper packet delivery during playback. 

1.1.1.3 Non-reaUtime recording/download 

To enlarge the fields of applications, non-real-time recording should be possible. 
However, in this case the STB has to generate the Time Stamp information. 

LLL4 Data allocation strategy 

Data allocation strategy and file system need to be designed to support real-time stream 
recording. The solution, which will be specified in the RTRW activity, should be studied 
and adopted as close as possible. 

2. 1. 1. 5 TOC and Service Information Support 

Many digital services require Service Information which normally is embedded in the real- 
time stream. To support the STB, DVD should provide additional space, which can be 
i^d by the STB to duplicate part of the service information and to add additional TOC 
information. 

1.1.1.6 Copy Protection Support 

The Copy Protection rules are discussed in CPTWG and WG9. These rules must be 
supported. In addition any scrambling performed by the service provider or the STB must 
be kept unchanged. In a later stage some joint discussion with SW owners and service 
providers might be needed. 

1.1.2 User Requirements 

User requirements can be grouped into requirements for recording, requirements for 
playback, and requirements for editing. 

(Requirements for Recording) 
1.1.2.1 Real-time Recording 

The format shotilck be designed to enable real-time recording of digital streams. It also 
should allow the user to concatenate recordings, even if those recordings consist of 



I- 



#&| : 0§#'98 17:19 TCE PATENTS GDRM«iEp&^d$1#;^ I ,'%- B ^^0^]i 

tce Ants germaKf y : : ": ' "i 

-DVD Stream Rec ordi ng - W 0 * WftMtt 

^ -THOMSON multimodia Confidential 2 

different stream formats. If recordings are concatenated, a (close to) seamless playback 
possibility would be nice but is not required. 

1. 1. 2. 2 Total Recording Time 

Regarding the recording time, the conditions are very similar to the RTRW scenario. 
Therefore the same rules should be valid. In any case the user must be able to 
understand the situation and to take appropriate action, if needed. 

1.1.2.3 Navigation Support 

To support navigation two pieces of information (lists) should be generated during 
recording. 

An 'original' version of a plav list . This list contains quite low level information, e.g. time 
map or (broadcast) packet order of the recording. This list is accessible by the STB and 
the content is understood by the DVD streamer as well as by the STB. In its 'original' 
version the playlist enables the playback of a complete recording. The playlist may be \ 
accessed and extended after recording by the STB to allow more sophisticated playback 
sequences. 

The second piece of information, mapping list, is generated to support the stream 
recorder to retrieve packet stream chunks (cells), that are described in terms of the 
application domain (e.g. 'broadcast packets' or 'time'). This list is owned and understood 
by the DVD streamer only. 

1.1.2.4 Content Description 

The format should reserve space, which can be used by the STB to store high level TOC 
and Service Information. This information is provided for the user to navigate through the 
content stored on disc and may contain sophisticated GUI information. The content is not 
needed to be understood by the stream recorder. However a common subset of the TOC 
information, e.g. based on a character string, may be useful to be shared between STB 
and DVD, in order to enable the stream recorder to provide a basic menu by itself. This 
may require some joint discussion with STB manufacturers. 

(Requirements for Playback) 

1.1. 2. 5 Playback of individual recordings 

Needs to be supported; should be possible via play list 

1.1.2. 6 Playing all recordings sequentially 

This is basically a set matter; should be possible via playlist. 

1.1.2. 7 Player menus for entry point selection 

This is mainly STB's responsibility, which can generate a sophisticated menu based on 
the TOC information stored on the disc. However, it should be possible to generate a 
simple menu by the streamer itself, e.g. via some 'character* information which is shared 
by STB and DVD. 

1.1.2.8 Trick play modes 

The STB should be able to steer trick play via the 'play list'. Due to the nature of the 
broadcast stream, the trick play features may be limited to basic ones, e.g. Time Search 
and Title Jump. 
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L 1. 2 9 User defined PB sequences 

Features like playback programming or parental control can be supported via the play list 
LL2.10 Play list support 

The playlist must be supported as a key for all special playback and navigation. 
LLZ11 Play list creation 

The DVD streamer should create the 'original version' of the play list. It also should allow 
extensions and modifications of the play list by the STB for more sophisticated playback 
features. The DVD streamer is not responsible for the content of those sophisticated 
playlist(s). 

(Requirements for Editing) 



2.12 Delete single recordings 
The format must support the deletion of single recordings on user's request 

1. 1. 2 13 Delete parts of recordings 

If possible, the format should allow this feature under the control of the STB. However, 
complex processing and knowledge on the service may be required for this functionality. 

1.2. 2 14 Inserting 

If possible, the format may support insert editing. This feature will probably require very 
complex processing and deep understanding of the service. An implementation, which will 
allow this feature, may be of semi-professional nature, 
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f.2 System Mode/ 

This specification is based on the following overall system model: 



Application 
Device 




Buffering & 
Timestamping 






— 


Buffering & 
Ttmestamp 
Handling 
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(e.g. IEEE1394) \ 




Figure 1-1 Overall System Model of DVD Stream Recording 
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f.3 Directory and File Structure 

The organization of Stream Data and Navigation Data of DVD Stream Recording is done 
in a specific way such as to take into account the following: 

• Any DVD Streamer Device has certain requirements to store its own 'housekeeping" 
data on the disc. These data are solely for helping the retrieval of recorded data; they 
need not be understood or even be visible to any outside Application Device. 

• Any DVD Streamer Device needs to communicate with the Application Device it is 
connected to. This communication should be straightforward, and as universal as 
possible, so that the maximum possible range of applications - both today and future - 
can be connected to the Streamer. The Navigation Data to support such 
communication must be understandable by the Streamer as well as by the Application 
Device. 

w^The Streamer Device should offer to the connected Application Device a means for 
^storing its own private data of any desired kind. The Streamer needs not to understand 
any of the content, internal structure, or meaning of this "Application Private Data". 

Figure 1-2 illustrates the directory and files where all the data comprising the disc content 
according to this Specification are recorded. Alt the files storing the disc content are 
placed under the STRREC directory. 



Root Directory 



STRREC Directory 









COMMON.IFO 


STREAMER. IFO 


APPLICAT.IFO 


REALTIME.SOB 



Other Directories 

Other Files 

Figure 1-2 Directory and File Configuration 

Under the STRREC directory, the following files are created: 

• COMMONJFO 

Basic information to describe the stream content, Needs to be understood by the 
Application Device as well as the Streamer. 

• STREAMER.! FO 

Private housekeeping information specific to the Streamer Device. Needs not to be 
understood by the Application Device. 

• APPUCATJFO 

Application Private Data, i.e. information that is specific to the Application(s) connected to 
the Streamer. Needs not to be understood by the Streamer. 
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• REALTIME.SOB 

Recorded real-time stream data proper. 

Note that except for the files described above, the STRREC directory shall not contain any 
other files or directories. 
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2 Navigation Data Structure 

Navigation data is provided to control the recording, playing back, and editing of any 
bitstreams that are recorded according to this Specification. As shown in Fig. 2-1, 
Navigation Data consists of Stream Management Information (SMI) as contained in the 
file named COMMON. IFO and of Housekeeping Information (HKPI) as contained in the 
file named STREAMER. IFO. 

From the point of view of the Streamer Device, these two kinds of information are 
sufficient to perform all necessary operations. Their details are described in Section 
u 2.1 Streamer Relevant Navigation Data" below. 



Stream Manager 
General Information 
(SIVLGI) 



Stream Title Table 
(STT) 



Stream Ptaylist Table 
(SPLT) 



Housekeeping 
General Information 
(HKP_GI) 



Housekeeping Address Table 
(HAT) 



Figure 2-1 Structure of DVD Streamer Navigation Data 

In addition to these, DVD Stream Recording also foresees the possibility of reserving a 
storage location for Application Private Data (APD), which may in general also be 
q^sidered as Navigation Data. See Section "2.2 Application Private Data" for Details. 

2. 1 Streamer Relevant Navigation Data 

As explained above, SMI and HKPI are the Navigation Data which are directly relevant for 
the Streamer operation. 

SMI consists of three kinds of Information tables, namely Stream Manager General 
Information (SM_GI), Stream Title Table (STT), and Stream Playlist Table (SPLT). These 
three tables shall all mandatorily be recorded and stored in the COMMON. IFO file in this 
order. 

HKPI consists of two kinds of information tables, namely Housekeeping General 
Information (HKP_GI) and Housekeeping Address Table (HAT). Both shall mandatorily be 
recorded and stored in the STREAMER. IFO file in this order. 

NB: Unlike in the 'DVD Specification for Read-Only Disc Part 3 VIDEO SPECIFICATION", 
where each table within Navigation Information shall be aligned on a sector boundary, 
there is no such restriction in Stream Recording. 
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2.1.1 Stream Manager General Information (SM_GI) 



RBP 




Contents 


Number of Bytes 


Oto 9 


STRMG ID 


STRMG Identifier 


10 


10 to 11 


reserved 


reserved 


2 


12 to 15 


SMI EA 


End address of SMI 


4 


16 to 27 


reserved 


reserved 


12 


28 to 31 


SMGI EA 


End address of SM Gl 


4 


32 to 33 


VERN 


Version number of DVD Streamer 
Specifications 


2 


34 to 127 


reserved 


reserved 


94 


128 to 129 


TM ZONE 


Time Zone 


2 


130 to 191 


reserved 


reserved 


62 


192 to 195 


STT SA 


Start Address of STT 


4 


196 to 199 


SPLT SA 


Start Address of SPLT 


4 


200 to 51 1 


reserved 


reserved 


312 



Total 



512 



(RBP 0 to 9) STRMGJD 

Describes "DVD_STR_MG" to identify Stream Recording Management Information File 
with character set code of IS0646 (a-characters). 

(RBP 12 to 15)SMl_EA 

Describes the end address of SMI with RLBN from the first LB of this SMI. 
(RBP 28 to 31) SMGIJEA 

Describes the end address of SMJ3I with RBN from the first byte of this SM_GI. 
(RBP 32 to 33) VERN 

Describes the version number of this Specification. 




Book Part version ... 0000b 0001b: version 0.1 

Others: reserved 

(RBP 128 to 129) TM.ZONE 

Describes the Time Zone for this Disc. All fields related to "Recorded Time" share this 
Time Zone value. The detailed structure for TM_ZONE is TBD. 

(RBP 192 to 195) STT_SA 

Describes the start address of STT with RBN from the first byte of this SM_GI. 
(RBP 196 to 199) SPLT.SA 

Describes the start address of SPLT with RBN from the first byte of this SM__GI. 
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2.1.2 Stream Title Table (STT) 



Stream Manager 
General Information 
(SM Gl) 




Stream PfayUst Table 
(SPLT) 



Figure 2-2 : Stream Title Table 
11.2.1 Stream Title Table General Information (STTJS1) 





Contents 


Number of Bytes 


(DST Ns 


Number of Stream Titles 


2 


(2) STT EA 


End Address of Stream Title Table 


4 


(3)STN CHRS 


Stream Title Name Character Set 


1 




Total 


7 



^ST_Ns 

Describes trie number of Stream Titles, which are described in this STT. The maximum 
allowable number of Stream Titles is 999. 

(2) STT_EA L _ 

Describes the End Address of Stream Title Table with RBN from the first byte of the STT. 

(1)STN_CHRS . ^ ^ 

Identifies the character set used for the Stream Title Names (STNs) in this STT. Details 

are TBD. 

2.1.2.2 Stream Title Entry (STE) 





Contents 


Number of Bytes 


(DAP PKT_SZ 


Application Packet Size 


2 


(2) SRV ID 


Service ID 


1 


(3) AP DEV ID 


Application Device ID 


12 


(4) ST DUR 


Stream Duration 


6 


(5) ST NM SRP 


Stream Name Search Pointer 


4 




Total 


25 
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(1) AP_PKT_SZ 

Describes the Application Packet Size in bytes. This packet size is valid for the entire 
stream title. 

NB: Due to the minimum transfer rate restriction rules described in Section „??", 
knowledge of the AP_PKT_SZ does not automatically and not for all streamer packets 
imply how many application packets are grouped together into the streamer packet. 

(2) SRVJD 

Describes an identifier of the digital service which created the stream of this title. Details 
of the identifier are TBD. 

(3) AP_DEV_ID 

Describes an identifier of the application device that was physically delivering the stream 
of this title. Details of the identifier are TBD. 

(4) STJDUR 

Describes the duration of the stream of this title, as resulting from the difference between 
the extended SCR of the last application packet of the stream minus the extended SCR of 
the first application packet of the stream. For the definition of Extended SCR, see 
Section „??". 

(5) ST_NM_SRP 

Describes the start address of the name string associated with this stream title, with RBN 
from the first byte of the STT. Name sharing shall not occur, i.e. each of the 
ST_NM_SRPs of the stream titles shall point to a different stream title name. 

2.1.2.3 Stream Title Name (STN) 





Contents 


Number of Bytes 


mST NAME 


Stream Title Name 


variable 



(1) ST__NAME 

Describes the Stream Title Name as a variable length string of characters from the 
character set identified by STN_CHRS of STTJ3I. 
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2.1.3 Stream Playlist Table (SPLT) 



Stream Manager 
General Information 
(5M_GI) 



Stream Title Table 
(STT) 




Figure 2-3 : Stream Playlist Table 
2. 1.3.1 Stream Playlist Table General Information (SPLTJjI) 





Contents 


Number of Bytes 


mSPL_Ns • 


Number of Playlists 


1 


(2) SPLT_EA 


End address of SPLT 


4 


(3) SPLN_CHRS 


Stream Playlist Name Character Set 


1 




Total 


6 



(1) SPL_Ns 

Describes the Number of playlists described in this SPLT. The maximum allowed number 
^playlists is 99. SPL_Ns also informs, how many SPl_SA and associated SPI are 
"uded in this SPLT. 

(2) SPLT_EA 

Describes the End Address of this SPLT with RBN from the first byte of this SPLT. 

(3) SPLN.CHRS 

Identifies "the character set used for the Stream Playlist Names (SPLNs) in this SPLT. 
Details are TBD. 



2.1.3.2 Stream Playlist Search Pointer (SPJSRP) 





Contents 


Number of Bytes 


(USPI SA 


Start Address of Playlist Information 


4 



(1)SPI_SA 

Describes the Start Address of the corresponding Stream Playlist Information, with RBN 
from the first byte of this SPLT. 
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2.1.3.3 Stream Play list Information (SP1) 





Contents 


Number of Bytes 


(1)PE Ns 


Number of Playlist Entries 


2 


(2) SPL CREATE TM 


Creation Time of this SPL 


5 


(3) SPL NAME 


Stream Playlist Name 


variable 



(1) PE_Ns 

Describes the Number of playlist entries of which this playlist consists. The maximum 
allowed number of playlist entries per playlist is TBD. PE_Ns also informs, which and how 
many of the subsequent PEs belong to this playlist. 

(2) SPL_CREATE_TM 

Describes the creation time of this playlist in STRR's Date and Time Describing format 
TBD. 

(3) SPL_NAME 

Describes the Stream Playlist Name as a variable length string of characters from the 
character set identified by SPLN_CHRS of SPLT_GI. 



2. 1. 3. 4 Playlist Entry Information 





Contents 


Number of Bytes 


(1)PE_ST_.N 


Index of Stream Title 


2 


(2)PE S SCR 


Start SCR 


6 


(3) PE E SCR 


End SCR 


6 




Total 


14 



(1) PE_ST_N 

Describes the index of the Stream Title to be played back for this PE. 

(2) PE_S_SCR 

Describes the Extended SCR value of the first application packet to be played back. 

(3) PE_E_SCR 

Describes the Extended SCR value of the last application packet to be played back. 
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2.1.4 Housekeeping General Information (HKP_GI) 





Contents 


Number of Bytes 


(1) HAE Ns 


Number of Housekeeping Address Entries 


2 


(2)HKPI EA 


End address of HKPI 


4 


(3)HKP TSCAL 


Time Scale Factor 


1 




Total 


7 



(1) HAE.Ns 

Describes the number of housekeeping address entries countained in this HKPI. The 
maximum allowed number of housekeeping adress entries is TBD. 

(2) HKPI_EA 

Describes the End Address of this HKPI with RBN from the first byte of this HKPI. 
(21HKP - TSCAL 

(JKcribes the time scaling used within this HKPI. Details of time scaling are TBD. 
2.1.5 Housekeeping Address Table (HAT) 

The purpose of this table is to provide all necessary information so that given playlist 
entries are efficiently translated into disc address pairs (from-to). - Bota il o of HAT ore TBD. 
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2.2 Application Private Data 

APD, if it exists, consists of three kinds of information, namely Application Private Data 
General Information (APD_G1), a set of one or more Application Private Data Search 
Pointer (APD_SRP), and a set of one or more Application Private Data Area (APDA). If 
any Application Private Data exists, these three kinds of information shall all mandatorily 
be recorded and stored in the APPUCAT.IFO file in this order. 

NB: Unlike in the "DVD Specification for Read-Only Disc Part 3 VIDEO SPECIFICATION" 
where each table within Navigation Information shall be aligned on a sector boundary, 
there is no such restriction in Stream Recording. 
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Figure 2-2 Application Private Data 
2.2.1 Application Private Data General Information 





Contents 


Number of Bytes 


(1) APDA Ns 


Number of Application Private Data Areas 


1 


(2) APD EA 


End Address of Application Private Data 


4 


(3) APDA SRVJD 


APD Area Sen/ice ID 


APDA Nsx4 



(1) APDA_Ns 

Describes the number of Application Private Data Areas, into which this APD is organized. 

(2) APD_EA 

Describes the end address of APD with RBN from the first byte of the APD. 

(3) APDA_SRVJD 

Describes a Service ID for each of the Application Private Data Areas to follow. For 
details of Service ID, see Annex A. 

2.2.2 Application Private Data Search Pointer 





Contents 


Number of Bytes 


(1) APDA SA 


Start address of APDA 


4 



(1 ) APDA_SA 
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Describes the start address of APDA with RBN from the first byte of APD. 





Contents 


Number of Bytes 


(1) APDA 


Application Private Data Area 


Variable 



(1) APDA 

Describes the Application Private Data. 
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3 Stream Data Format 

Stream Data according to this Specification consists of one or more „Stream Objects" 
(SOBs) which are each stored as a .Program stream" as described in [MPEG-2 Systems]. 
A SOB has the following restrictions: 

1 . Each SOB shall be terminated by a program_end__code. 

2. The value of the SCR field in the first pack of each SOB may be non-zero. 

A SOB contains the Stream Data packed into a sequence of .Stream Packs" (S_PCKs). 
The transfer rate of SOBs shall obey the restrictions listed in Table 3-1. 
Table 3-1 : Restrictions on transfer rate of Stream Data 



Minimum Transfer rate 


TBD 


Maximum Transfer Rate 


TBD 



Stream Data described under this Specification are organized as one elementary stream 
and are carried in PES packets with a stream Jd of of private_stream_1 . In some other 
formats of the DVD family, private_stream_1 is also used to carry several kind of non- 
MPEG AV Presentation Data. As a means of distinction among these, the first byte of the 
data area of each packet is used as w sub_stream_id tt ( DVD Stream Recording, although 
already separated by the use of a different directory for its data, shares this principle, i.e. 
the first byte of data area is used as a sub_stream_id and is entered as a new, unique 
value of TBD designating the subsequent payload as „Stream Recording Data". 

3.1 Stream Object 

A stream Object is composed of one or more Stream Packs (S_PCKs) as shown in Fig 3-1 



Stream Object (SOB) 



S_PCK 



S^PCK 



S^PCK 



S PCK 



S_PCK 



S_PCK 



Figure 3-1 : Structure of a Stream Object 

Because the length of a SOB is basically arbitrary, the last S_PCK of a SOB might employ 
padding in one of two different ways. For details see Section ??. 

3.2 Stream Pack 

Stream Packs are „Program Stream Packs' 1 in the sense of [MPEG2 System] and comply 
with all rules given there. The pack length is 2048 bytes (one LB) and a pack is recorded 
in one LB. 
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A Stream Pack consists of one pack header, followed by zero or one system header, and 
followed by one Stream Packet (SJ>KT). An extra padding packet will not be employed, 
as shown in Figure 3-2. 



-One Stream Pack- 



Pack 
header 



System 
header* 



Stream Packet 



14 bytes 24 bytes' 

* may or may not exist 

Figure 3-2 : Structure of a Stream Pack 



A system header is included exactly in those S_PCKs, which are the first S_PCK of a 
SOB. When a system header is included, the length of the remaining Stream Pack content 
is 2010 bytes, when it is not included, the length of Stream Pack content is 2034 bytes. 

In Stream recording, the application performs its own padding, so that the pack length 
adjustment methods of DVD-ROM Video or RTRW need not to be used. In Stream 
recording it is safe to assume, that the Stream packets will always have the necessary 
length. 

3.2.1 Pack Header 
Table 3-3 : Pack header 



Field 


Number 
of bits 


Number 
of bytes 


Value 


Comment 


BBck start code 


32 


4 


0000 01BAh 






2 


6 


provider 
defined 


01b 


SCR base[32..30] 


3 


(NoteD 


marker bit 


1 


1 


SCR base[29..15] 


15 




marker bit 


1 


1 


SCR basef14..0] 


15 




marker bit 


1 


1 


SCR extension 


9 




marker bit 


1 


1 


program mux_rate 


22 


3 


01 3883h 


muxj-ate = 8Mbps (Note 2) 


marker bit 


1 


1 


marker bit 


1 


1 


reserved 


5 


1 


F8h 


11111b 


pack_stuffing length 


3 


no stuffing length = 000b 



Note 1: „SCRj3ase[32]" shall be set to ZERO. 
Note 2: „program_mux_rate u shall be set to 8Mbps. 
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3.2.2 System Header 



Table 3-4 : System header 





Number 
of bits 


Number 
of bytes 


Value 


Comment 


system_header_starLcode 


32 


4 


OOOOOIBBh 




header length 


16 


2 






markenblt 


1 






1 


rate_bound 


22 


3 


809C41h 


mux_rate = 8Mbps 


marker_bit 


1 






1 


audio_bound 


6 




0 


No audio streams 


fixed Jag 


1 




0 


Variable bit rate 


CSPSJlag 


1 




1 orO^. 




system.audiojockjag 


1 


2 


1 




system_videoJock_flag 


1 




1 


1 


marker_bit 


1 




1 


1 


video.bound 


5 




0 


No video streams 


packeLrate_restriction_flag 


1 


1 


OoM 




reserved Jiits 


7 




7Fh 




streamjd 


8 


1 






'11' 


2 




11b 




P-STD_buf_bound_scale 


1 


2 


1 


buLsizex 1024 bytes 


P-STD J>uf_sizeJ>ound 


13 




232 


buLsize = 237568 bytes 


streamjd 


8 


1 






'11* 


2 




11b 




P-STD J>uf_bound__scale 


1 


2 


0 


buf_sizex 128 bytes 


P-STD J>uf_sizeJ)ound 


13 




32 


buLsize = 4096 bytes 


streamjd 


8 


1 


1011 1101b 


private_streamj 


'1V 


2 




11b 




P-STD_buf_bound_scale 


1. 


2 


1 


buLsize x 1024 bytes 


P-STD buf size_bound 


13 




58 


buLsize = 55392 bytes 


streamjd 


8 


1 


1011 1111b 


private_stream_2 


'11' 


2 




11b 




P-STD J>uLbound__scale 


1 


2 


1 


buLsize x 1024 bytes 


P-STD Jsuf_sizeJ>ound 


13 




2 


buLsize = 2048 bytes 



3.3 Stream Packet 

In Stream Packets, no stuffing takes place and each Stream packet has just DTS, no PTS. 
Packet header size therefore is 14 bytes constant. 
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3.3.1 Packet Header 



Field 


Number 
or Drts 


Number 
of bytes 


Value 


Comment 


packet start code prefix 


24 


3 


uu uuu i n 




stream id 


8 


1 


•i ni 444 ni k 

nun nun d 


pri vaie _ou earn i 


PES packet lenqth 


16 


2 






•10' 


2 


3 


lub 




PES scrambling control 


2 




I oU 


PES priority 


1 


0 


no pnoriiy 


data alignment indicator 


1 


0 


not aennea oy aescnpior 


copyright 


1 


0 


not defined by descriptor 


original or copy 


1 


0 


copy 


PTS DTS flags 


2 


10b 




ESCR flag 


1 


0 


no ESCR field 


flPrate flag 


1 


0 


no ES rate field 


DSM trick_mode flag 


1 


0 


no trick mode field 


additional copy infojflag 


1 


0 


no copy info field 


PES CRC flag 


1 


0 


no CRC field 


PES extension flag 


1 


0 


no extension 


PES header datajength 


8 


5 




'0001' 


4 


5 


Provider 
defined 




DTSf32..30] 


3 




marker bit 


1 




DTSI29..151 


15 




marker bit 


1 




DTSH4..01 


15 




marker bit 


1 




stuffing byte 




0to7 






Private data area 



stream id 



8 



1 



TBD 



Stream data area 



3.3.2 Stream Data area 

The Stream data area inside a Stream Packet consists of an application header, an 
application header extension, and a sequence of application packets, each prefixed by an 
application packet timestamp. 
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Field 


Number 

Of DltS 


Number 
of bytes 


value 


Comment 


(1) MAX B URATE 


32 


4 






(2) SMOOTH BUF SIZ 


15 




oo4vj oytes 




ZO\ TO PCC r*i PPPH 




4 

•t 


07 MHz 




(4)AP PKT LEN 


16 


2 






(5)TS LEN 


8 


1 


'4' 




(6)AP PKT Ns 


8 


1 






(7) START OF STR 


1 


1 


Ob or 1b 




(8) END OF STR 


1 


Ob or 1b 




reserved 


6 








Total 


15 







(1) M ARBITRATE 

Describes the output bitrate parameter of the leaky bucket flow control model In Mbps. 

(2) SMOOTH^BUF^SIZ 

Describes the buffer size parameter of the leaky bucket flow control model. 

(3) TS_REF_CL - FREQ 

Describes the reference clock frequency of the packet arrival/delivery timestamp. 

(4) AP — PKT^LEN 

Describes the length of the application packet 

(5) TS_LEN 

Describes the length of the timestamp field. 

(6) AP_PKT.Ns 

The number of application packets in this DVD pack. 

(7) START_OF_STR 

When set to '1 \ this packet is the first DVD pack in the stream. 

(8) END_OF_STR 

When set to '1 *, this packet is the last DVD pack in the stream. 



3.3.2*2 Application Header Extension 

The application header extension consists of a list of entries, where there is exactly one 
entry for each transport layer packet These bytes are used to store information that may 
differ from packet to packet. 

The total length of the application header extension shall be 46 bytes. The first 
# AP_PKT_Ns' entries of these shall carry valid data. Unused list entries may carry 
undefined values. 

The total length of 'application header* and 'application header extension 1 shall be 61 
bytes. 
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Field 


Number 
of bits 


Number 
of bytes 


Value 


Comment 


fDAU START 


1 








(2)AU END 


1 


1 






(3) reserved 


4 








(4) COPYRIGHT 


2 









(1)AU_START 

When set to '1', indicates that the associated application packet contains a random 
access entry point into the stream 



^^en 



fen set to '1 indicates the associated application packet is the last packet of a random 
access point. 
(4) COPYRIGHT 

Describes the copyright status of the associated application packet, ©ctoils arc TDD 
3.3.2.3 Time Stamps 



List of Abbreviations 

LB Logical Block 

RBN Relative Byte Number 



RBP Relative Byte Position 

RLBN Relative Logical Block Number 
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Stream recording assumes an "application Device" (e.g. set top box) connected 
to a DVD Streamer. They are connected e.g. via IEEE1394, which in its 
transmitting and receiving firmware contains means to timestamp data, and to 
strip off these timestamps again, using them for timing regeneration. The effect 
of this is that between the input of 1394 and its output, it behaves like a 
constant delay system. Normally, the dvd Streamer then has a similar task, and 
will be using similar method: the streamer must regenerate the timing of data 
packets as it was upon recording, when these packets are played back, so that 
between recording and playback, it also behaves like a constant delay system. 



The streamer, too, can use timestamps and strip them off again, using them for 
timing regeneration. 

So, in total, we have an "in series" connection between two time stamping 
/&time regeneration mechanisms, this series connection involves some jitter 
accumulation. 



Now, the invention proposes that the application device itself, before sending 
the data thru the 1394, adds time stamps UJo the data packets, these 
timestamps have the meaning of "departure time" rather that arrival time, these 
time stamps then go thru the 1394 "unnoticed* (i.e. froim 1394 point of view 
they are part of the payload), and on the other end of the chain, these 
timestamps can be used when the dvd streamer plays back a stream. The 
advantage is that there is just one timing/regeneration process involved, no 
jitter accumulation takes place. 



Ill 



Claim 



1. Method for timestamping a bitstream to be recorded or for 
using times tamps recorded on a storage medium, e.g. a DVD 
5 recorder, wherein a device outputting said bitstream to 

be recorded adds said timestamps to data packets of said 
bitstream and wherein said timestamps represent a depar- 
ture time instead of an arrival time, and wherein the 
bitstream passes through an IEEE1394 connection for which 
10 said timestamps belong to the payload and said timestamps 

are also used when replaying said bitstream. 
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